home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-sdr-pl-00.txt < prev    next >
Text File  |  1993-07-08  |  19KB  |  615 lines
  1.  
  2. SDR Working Group                                            Tony Li
  3. INTERNET DRAFT                                         cisco Systems
  4.                                                              6/21/93
  5.  
  6.  
  7.                  Source Demand Routing Policy Language
  8.  
  9.  
  10.  
  11.                           Status of this Memo
  12.  
  13.    This document defines a policy language for use with the SDRP policy
  14.    routing protocol for the Internet. This document specifies an IAB
  15.    standards track protocol for the Internet community, and requests
  16.    discussion and suggestions for improvements.  Please refer to the
  17.    current edition of the "IAB Official Protocol Standards" for the
  18.    standardization state and status of this protocol.  Distribution of
  19.    this document is unlimited.
  20.  
  21.    This document is an Internet Draft. Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups. Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time. It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a "working
  30.    draft" or "work in progress".
  31.  
  32.  
  33. 1  Overview
  34.  
  35.  
  36.    The purpose of SDRP [1] is to support source-initiated selection of
  37.    routes to complement the route selection provided by existing routing
  38.    protocols for both inter-domain and intra-domain routes.  This
  39.    document refers to such source-initiated routes as "SDRP routes".
  40.    For the computation of inter-domain routes, it is useful to be able
  41.    to remotely request policy information from other routing domains.
  42.    This document describes a mechanism and a language for exchanging
  43.    policy information.  The language provides a common, extensible,
  44.    machine interpretable basis for determining if a packet flow is in
  45.    compliance with the policies of the remote domain.
  46.  
  47.    Note that in this scheme, only certain transit and destination
  48.    policies can be described.  This scheme allows a domain to describe
  49.    accessibility policies, but does not permit the encoding of route
  50.  
  51.  
  52.  
  53. Expiration Date Dec. 1993                                       [Page 1]
  54.  
  55. INTERNET DRAFT                                                 June 1993
  56.  
  57.  
  58.    preferences.  Source policies remain private to the originating
  59.    domain.
  60.  
  61.  
  62. 2  Policy requests and replies
  63.  
  64.  
  65.    Requests for remote policies and replies are sent as SDRP control
  66.    messages.  Policy requests are sent with a Notification Code of 8,
  67.    for "Policy Request", and replies are send with a Notification Code
  68.    of 9, for "Policy Reply".  The payload of both messages is used to
  69.    convey the policy information.  For a Policy Request control message,
  70.    the payload has the format:
  71.  
  72.        0                   1                   2                   3
  73.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  74.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  75.       |      Authentication Code      |     Authentication Data ...
  76.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  77.  
  78.    For a Policy Reply control message, the payload has the format:
  79.  
  80.        0                   1                   2                   3
  81.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  82.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  83.       |      Authentication Code      |         Policy Length         |
  84.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  85.       |                              TTL                              |
  86.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  87.       |                       Policy Information ...
  88.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  89.       |                       Authentication Data ...
  90.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  91.  
  92.       Authentication Code (2 octets) and Authentication Data (variable)
  93.  
  94.          The Authentication Code is a 2 octet unsigned integer that
  95.          indicates the authentication mechanism being used.  Whenever an
  96.          authentication mechanism is specified for use within SDRP,
  97.          three things must be included in the specification:
  98.  
  99.          - the value of the Authentication Code that indicates use of
  100.          the mechanism,
  101.          - the form and meaning of the Authentication Data in Policy
  102.          Request messages, and
  103.          - the form and meaning of the Authentication Data in Policy
  104.          Reply messages.
  105.  
  106.  
  107.  
  108.  
  109. Expiration Date Dec. 1993                                       [Page 2]
  110.  
  111. INTERNET DRAFT                                                 June 1993
  112.  
  113.  
  114.          Only one authentication mechanism is specified as part of this
  115.          memo:
  116.  
  117.          - its Authentication Code is zero,
  118.          - its Authentication Data field has zero length in both Policy
  119.          Request and Policy Reply messages.
  120.  
  121.          The semantics of non-zero Authentication Codes lies outside the
  122.          scope of this document.
  123.  
  124.       Policy Length (2 octets)
  125.  
  126.          The Policy Length field is a 2 octet unsigned integer that
  127.          indicates the number of octets of policy information that is
  128.          contained in a Policy Reply message.
  129.  
  130.       TTL (4 octets)
  131.  
  132.          The TTL field is a four octet unsigned integer.  This field is
  133.          the time to live of the Policy Reply and indicates the number
  134.          of seconds that the Policy Reply may be cached.
  135.  
  136.       Policy Information (variable)
  137.  
  138.          The Policy Information field is a variable length field that
  139.          contains the transit and destination policies of the domain
  140.          sending the Policy Reply message.  The Policy Information is
  141.          encoded in the SDRP policy language described below.
  142.  
  143.  
  144. 3  SDRP Policy Language
  145.  
  146.  
  147.    The language used for transmission of policy information is a simple,
  148.    extensible, easily interpreted form of a boolean expression.  A
  149.    system that wishes to evaluate a policy for a particular packet or
  150.    flow need only substitute appropriate values in the expression.  A
  151.    result of true indicates that the packet or flow is permissible
  152.    within the policy.  To aid in debugging and implementation, the
  153.    policy language is distributed in ASCII.  The additional bandwidth
  154.    consumed by not encoding it in binary is expected to be negligible
  155.    since policies change infrequently and can be cached for a relatively
  156.    long time.  The language presented here is loosely based on the
  157.    language 'C' [2].
  158.  
  159.    In general, a policy expression is syntactically a 'C' expression,
  160.    but no bit manipulations are allowed.  An additional "OR" separator
  161.    has been added to the language that allows simple separation of
  162.  
  163.  
  164.  
  165. Expiration Date Dec. 1993                                       [Page 3]
  166.  
  167. INTERNET DRAFT                                                 June 1993
  168.  
  169.  
  170.    different parts of a policy for independent evaluation.
  171.  
  172.  
  173. 3.1 Syntax
  174.  
  175.  
  176.    Spaces, tabs and newlines are ignored except as token separators.
  177.    Identifiers are sequences of letters and digits, the first character
  178.    must be a letter.  Identifiers are case sensitive.  The remainder of
  179.    the syntax is described in a variant of BNF in which terminals are
  180.    enclosed in double quotes.  Alternatives for productions are listed
  181.    on separate lines.
  182.  
  183.            policy:
  184.                    expression
  185.                    policy "OR" expression
  186.  
  187.            expression:
  188.                    OR-expression
  189.                    OR-expression "?" expression ":" expression
  190.  
  191.            OR-expression:
  192.                    AND-expression
  193.                    OR-expression "||" AND-expression
  194.  
  195.            AND-expression:
  196.                    equality-expression
  197.                    AND-expression "&&" equality-expression
  198.  
  199.            equality-expression:
  200.                    relational-expression
  201.                    equality-expression "==" relational-expression
  202.                    equality-expression "!=" relational-expression
  203.  
  204.            relational-expression:
  205.                    additive-expression
  206.                    relational-expression "<" additive-expression
  207.                    relational-expression ">" additive-expression
  208.                    relational-expression "<=" additive-expression
  209.                    relational-expression ">=" additive-expression
  210.  
  211.            additive-expression:
  212.                    multiplicative-expression
  213.                    additive-expression "+" multiplicative-expression
  214.                    additive-expression "-" multiplicative-expression
  215.  
  216.            multiplicative-expression:
  217.                    unary-expression
  218.  
  219.  
  220.  
  221. Expiration Date Dec. 1993                                       [Page 4]
  222.  
  223. INTERNET DRAFT                                                 June 1993
  224.  
  225.  
  226.                    multiplicative-expression "*" unary-expression
  227.                    multiplicative-expression "/" unary-expression
  228.                    multiplicative-expression "%" unary-expression
  229.  
  230.            unary-expression:
  231.                    primary-expression
  232.                    unary-operator unary-expression
  233.                    "(" expression ")"
  234.  
  235.            primary-expression:
  236.                    identifier
  237.                    constant
  238.                    IPaddr
  239.  
  240.            IPaddr:
  241.                    octet "." octet "." octet "." octet
  242.  
  243.            unary-operator:
  244.                    "-"
  245.                    "!"
  246.  
  247.    A constant is a 4 octet unsigned integer.  Syntactically, it may be
  248.    specified as a string of decimal digits from "0" to "9", or as a
  249.    string of hexidecimal digits if preceeded by "0x" or "0X".  The
  250.    hexidecimal digits are "0" to "9", "a" to "f", and "A" to "F".  An
  251.    octet is specified as a string of decimal digits from "0" to "9", and
  252.    the resulting value must be between 0 and 255.
  253.  
  254.  
  255. 3.2 Semantics
  256.  
  257.  
  258.    The semantics for most of this language are taken directly from [2],
  259.    which should be considered authoritative for all constructs that are
  260.    taken from "||" operator.  An IPaddr is semantically equivalent to a
  261.    constant.
  262.  
  263.    Thus, evaluation of a policy produces a boolean result, either 0 or
  264.    1.  Evaluation of the null policy (the empty string) produces the
  265.    result 0.  A result of 0 indicates that the policy has not been
  266.    satisfied and that the this route should not be used.  A result of 1
  267.    indicates that the route is permissible with respect to this policy.
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277. Expiration Date Dec. 1993                                       [Page 5]
  278.  
  279. INTERNET DRAFT                                                 June 1993
  280.  
  281.  
  282. 3.3 Variables
  283.  
  284.  
  285.    Identifiers that appear in policies are variables that describe some
  286.    attribute of the data flow.  For each variable used in this language,
  287.    there must be a written specification of the variable that includes
  288.    the name of the variable and the semantics of the variable.
  289.  
  290.    The value of the variable may be dependent on the traffic in the
  291.    flow, external physical constants, or other systems.  Any two systems
  292.    that support a particular variable must attach identical semantics to
  293.    the variable.  If a system does not support a variable that occurs in
  294.    a policy, the entire expression containing that variable must
  295.    evaluate to 0.
  296.  
  297.  
  298. 3.4 Base variables
  299.  
  300.  
  301.    This document specifies the following variables:
  302.  
  303.  
  304. 3.4.1   src_address
  305.  
  306.  
  307.    The variable "src_address" is the source IP address for packets in
  308.    the flow.
  309.  
  310.  
  311. 3.4.2   dst_address
  312.  
  313.  
  314.    The variable "dst_address" is the destination IP address for packets
  315.    in the flow.
  316.  
  317.  
  318. 3.4.3   ip_tos
  319.  
  320.  
  321.    The variable "ip_tos" is the IP Type Of Service octet for packets in
  322.    the flow.  Note that the value of the entire octet is used [5].
  323.  
  324.  
  325. 3.4.4   ip_protocol
  326.  
  327.  
  328.    The variable "ip_protocol" is the Protocol field from the IP header
  329.    for packets in the flow.
  330.  
  331.  
  332.  
  333. Expiration Date Dec. 1993                                       [Page 6]
  334.  
  335. INTERNET DRAFT                                                 June 1993
  336.  
  337.  
  338. 3.4.5   hour
  339.  
  340.  
  341.    The variable "hour" is the current hour, in UTC.  An implementation
  342.    supporting this variable must derive the current time from a reliable
  343.    source, such as [2] or [3].
  344.  
  345.  
  346. 3.4.6   minute
  347.  
  348.  
  349.    The variable "minute" is the current minute, in UTC.  An
  350.    implementation supporting this variable must derive the current time
  351.    from a reliable source, such as [2] or [3].
  352.  
  353.  
  354. 3.4.7   day
  355.  
  356.  
  357.    The variable "day" is the current day of the week for UTC.  The
  358.    following table lists days and corresponding values.  An
  359.    implementation supporting this variable must derive the current time
  360.    from a reliable source, such as [2] or [3].
  361.  
  362.            Value   Day
  363.            -------------------
  364.            0       Monday
  365.            1       Tuesday
  366.            2       Wednesday
  367.            3       Thursday
  368.            4       Friday
  369.            5       Saturday
  370.            6       Sunday
  371.  
  372.  
  373. 3.4.8   date
  374.  
  375.  
  376.    The variable "date" is the current day of the month for UTC.  Legal
  377.    values are 1 through 31.  An implementation supporting this variable
  378.    must derive the current time from a reliable source, such as [2] or
  379.    [3].
  380.  
  381.  
  382. 3.4.9   month
  383.  
  384.  
  385.    The variable "month" is the current month for UTC.  The following
  386.  
  387.  
  388.  
  389. Expiration Date Dec. 1993                                       [Page 7]
  390.  
  391. INTERNET DRAFT                                                 June 1993
  392.  
  393.  
  394.    table lists months and their corresponding values.  An implementation
  395.    supporting this variable must derive the current time from a reliable
  396.    source, such as [2] or [3].
  397.  
  398.            Value   Month
  399.            -------------------
  400.            1       January
  401.            2       February
  402.            3       March
  403.            4       April
  404.            5       May
  405.            6       June
  406.            7       July
  407.            8       August
  408.            9       September
  409.            10      October
  410.            11      November
  411.            12      December
  412.  
  413.  
  414. 3.4.10   year
  415.  
  416.  
  417.    The variable "year" is the current year for UTC.  Legal values are
  418.    integers greater than or equal to 1993.  An implementation supporting
  419.    this variable must derive the current time from a reliable source,
  420.    such as [2] or [3].
  421.  
  422.  
  423. 3.4.11   src_port
  424.  
  425.  
  426.    The variable "src_port" is the source port for TCP or UDP packets for
  427.    packets in the flow.
  428.  
  429.  
  430. 3.4.12   dst_port
  431.  
  432.  
  433.    The variable "dst_port" is the destination port for TCP or UDP
  434.    packets for packets in the flow.
  435.  
  436.  
  437. 3.4.13   new_connection
  438.  
  439.  
  440.    The variable "new_connection" has value 0 for TCP packets that have
  441.    the ACK or RST bit set and the value 1 otherwise.  A frequent
  442.  
  443.  
  444.  
  445. Expiration Date Dec. 1993                                       [Page 8]
  446.  
  447. INTERNET DRAFT                                                 June 1993
  448.  
  449.  
  450.    application is deny new connections to particular ports in the
  451.    destination domain.
  452.  
  453.  
  454. 3.5   Future research
  455.  
  456.  
  457.    We would also like to be able to create variables that represent the
  458.    domain of the source and the domain of the destination.  However no
  459.    standard mechanism exists for determining this information
  460.    dynamically.
  461.  
  462.    We would also like to be able to classify the community associated
  463.    with a particular traffic flow, such as Research, Education,
  464.    Commercial, or Government.
  465.  
  466.    There has also been some discussion about performing pattern matching
  467.    on the entire SDRP route.  The utility of this is not yet clear and
  468.    is a matter for future research.  This may require adding pattern
  469.    matching primitives to the language.
  470.  
  471.    A frequent request is the ability to determine the utilization of
  472.    inter-domain links.  There is currently no standard mechanism for
  473.    relaying this information.  Note that if such a mechanism is
  474.    developed, it should be independent of this policy language, possibly
  475.    as another component to SDRP.
  476.  
  477.  
  478. 4  Examples
  479.  
  480.  
  481.    This section demonstrates how this policy language might be used.
  482.    Suppose that a company `SANFRAN' has many interconnections to a
  483.    number of different networks.
  484.  
  485.    Suppose that SANFRAN agrees that a local eductional institution may
  486.    use its domain as a transit.  The educational institution uses
  487.    network address 63.0.0.0, and all packets destined or sourced from
  488.    this network would be permitted:
  489.  
  490.            (src_address > 63.0.0.0) && (src_address < 63.255.255.255) ||
  491.            (dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255)
  492.  
  493.    SANFRAN then decides that this is too restrictive and it also wishes
  494.    to provide transit service for DNS.  DNS uses port 53 over both TCP
  495.    (protocol 6) and UDP (protocol 17):
  496.  
  497.            (src_address > 63.0.0.0) && (src_address < 63.255.255.255) ||
  498.  
  499.  
  500.  
  501. Expiration Date Dec. 1993                                       [Page 9]
  502.  
  503. INTERNET DRAFT                                                 June 1993
  504.  
  505.  
  506.            (dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255)
  507.            OR
  508.            ((src_port == 53) || (dst_port == 53) &&
  509.            (ip_protocol == 6) || (ip_protocol == 17))
  510.  
  511.    SANFRAN also wishes to allow all Research networks to use it as a
  512.    transit.  To do this, it makes use of a new variable called
  513.    "community", for which the Research community has the value 4:
  514.  
  515.            ...
  516.            OR
  517.            community == 4
  518.  
  519.    This policy will be ignored by any SDRP speaker which does not
  520.    support that variable.
  521.  
  522.    SANFRAN also is willing to provide transit service after business
  523.    hours, on weekends and on Groundhog day.  This policy allows traffic
  524.    between the hours of 1100UTC and 1900UTC, on Saturday and Sunday, and
  525.    on Feb. 2nd:
  526.  
  527.            ...
  528.            OR
  529.            (hour >= 1100) && (hour <= 1900) ||
  530.            (day == 5) || (day == 6) ||
  531.            (month == 2) && (date == 2)
  532.  
  533.  
  534. 5 Security Considerations
  535.  
  536.    Security issues are not discussed in this memo.
  537.  
  538.  
  539. 6 Acknowledgements
  540.  
  541.  
  542.    The author would like to express his thanks to Deborah Estrin
  543.    (USC/ISI), Steve Hotz (USC/ISI), and Yakov Rekhter (IBM) for their
  544.    insightful comments and assistance.
  545.  
  546.  
  547. 7 Author's Address
  548.  
  549.  
  550.    Tony Li
  551.    cisco Systems, Inc.
  552.    1525 O'Brien Drive
  553.    Menlo Park, CA 94025
  554.  
  555.  
  556.  
  557. Expiration Date Dec. 1993                                      [Page 10]
  558.  
  559. INTERNET DRAFT                                                 June 1993
  560.  
  561.  
  562.    Phone: (415) 688-8186
  563.    email: tli@cisco.com
  564.  
  565.  
  566. 8 References
  567.  
  568.  
  569.    [1] Estrin, D., Li, T., Rekhter, Y., "Source Demand Routing: Packet Format
  570.    and Forwarding Specification (Version 1)", work in progress
  571.  
  572.    [2] Kernighan, B.W., Ritchie, D.M., "The C Programming Language", Second
  573.    Edition, Prentice-Hall, New Jersey, 1998
  574.  
  575.    [3] Mills, D.L., "Simple Network Time Protocol (SNTP)", RFC 1361, August
  576.    1992
  577.  
  578.    [4] Mills, D.L., "Network Time Protocol (Version 3): Specification,
  579.    implementation, and analysis", RFC 1305, March 1992
  580.  
  581.    [5] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC
  582.    1349, July 1992
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Expiration Date Dec. 1993                                      [Page 11]
  614.  
  615.